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DISCUSSION OF THREE TYPICAL LANGLEY RESEARCH CENTER 

SIMULATION PROGRAMS 
By Ellis <T * White 

ABSTRACT 


This discussion deals with three typical simulation programs at 
Langley in the areas of aerodynamic flight, lunar flight, and near-earth 
space flight. The simulation requirements in terms of the mission, the 
vehicle, and the simulation hardware are discussed for each problem. 

The mathematical models are mentioned in general and particular emphasis 
is given to the computer considerations of each in terms of the layout 
and the size and types of computers utilized. The computational consid- 
erations such as integration schemes, sampling rates, and central 
processing unit time of an all-digital approach to an earth orbit rendez- 
vous problem is presented and the results compared to a hybrid approach. 
Capabilities of Langley's future digital simulation complex are discussed. 
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DISCUSSION OF THREE TYPICAL LANGLEY RESEARCH CENTER 

SIMULATION PROGRAMS 

By Ellis J . White 
Langley Research Center 

INTRODUCTION 

The purpose of this presentation is to acquaint other users and 
manufacturers of computing equipment with the computer approach made 
at the NASA Langley Research Center to real-time simulation problems 
in the research areas of aerodynamic flight, lunar flight, and near- 
earth space flight. A typical problem will be used to illustrate the 
work in each of these three areas. These problems are: first, 

super sonic- transport air-traffic- control studies; second, lunar-orbit 
and landing-approach studies for vehicles of the Apollo lunar module (LM) 
type; and finally, a study for earth-orbit ’’station keeping” of the 
Gemini and Agena vehicles. The emphasis in this discussion will be on 
computer considerations (choice of computers, layout, etc.) with respect 
to the simulation requirements in terms of the missions, the vehicles, 
and the hardware. Th-: mathematical models are not discussed in any 
detail, but are given attention when they were influenced by computer 
considerations and simulation requirements, and vice versa. None of the 
research results obtained by use of these simulators will be discussed. 
The three typical programs will demonstrate the use of the existing 
Langley computer equipment in termo of an all-analog problem, a ’’hybrid 
program” using analog and a Digital Differential Analyzer (TRICE-DBA), 
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and an experimental all-digital-simulation program using the IBM 709411 
and TRICE conversion equipment. The digital simulation problem, which 
is the earth-orbit station keeping of the Gemini and Agena vehicles, was 
also done on a production basis using an analog-DDA combination. Some 
general comparisons of these two approaches will be discussed. Also, 
a short general description of Langley’s future computer complex will be 
discussed and some of its simulation capabilities outlined. It should 
be mentioned here that this discussion is not meant to imply that this 
approach is the only one that can be made to these problems, but is one 
that has been very successful with the available equipment. 

SUPERSONIC-TRANSPORT AIR- TRAFFIC- CONTROL STUDIES 
General Considerations 

The supersonic-transport project was a joint NASA-PAA study of a 
real-time simulation of supersonic transport (SST) arrivals and departures 
at large international airports. The objectives of the study were: 

1. To determine the effects of the air-traffic-control (ATC) system 
on SST design and equipment requirements. 

2. To determine the effects of the SST on ATC system requirements. 

• • • 

Simulation Requirements 

Some pertinent characteristics of the mission, the vehicle, and 
the hardware, which determine the simulation requirements are now discussed: 

Mission .- Mission characteristics include: 

(1) Mach number range from 0 to 4.0. 

(2) Altitude from sea level to 100,000 feet. 
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Vehicle .- Vehicle characteristics to he considered are: 

(1) Inclusion of both fixed- geometry and variable- sweep 

wing concepts. 

(2) Complete six- degree -of- freedom representation. 

(5) Provision for four completely independent engines. 

Hardware and overall simulator .- A block diagram of the facilities 
involved in the program is shown in figure 1. The blocks on the left 
represent the equipment at NASA Langley Research Center in Hampton, 
Virginia, and those on the right represent the equipment at FAA’s National 
Aviation Facilities Experimental Center (NAFEC) in Atlantic City, 

New Jersey. The analog computing facility, which is used to solve the 
equations of motion and will be discussed later, is coupled to the SST 
simulator flight compartment via underground cables. The«e two facilities 
are separated by approximately 1,000 feet. The SST position data and 
the voice communication between NASA and FAA are transmitted via telephone 
lines after the signals are converted from analog to digital. To create 
the air-traffic- control environment, the FAA has provided an entire 
Air Route Traffic Control Center and an approach control and tower complex 
for one airport. These facilities are staffed by 30 experienced air 
traffic controllers. They are provided with radar display including 
video maps showing airways, holding and terminal areas, flight progress 
strips, and radio communication equipment. The Air Traffic Sample Simula- 
tion is created by 108 personnel each operating an electronic target 
generator, which provides beacon information for the controller’s radar 
scopes. Each operator, by adjusting controls and actuating switches, 
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simulates one aircraft moving along a preprogramed flight path. 

Figure 2 shows the Langley SST cockpit’ and control room. The flight 
compartment is similar to that of a current Jet transport aircraft 
with seating for pilot, copilot, flight engineer, navigator, and an 
observer. The instrumentation is also similar except some of the 
instrument ranges are modified to cover the higher altitude and Increased 
Mach number. Accessory equipment needed to provide for navigation, 
communication, recording, and power requirements is located in a room 
behind the cockpit. 

Mathematical Model and Computer Considerations 
Figure 3 shows the computer equipment requirements and organization 
for the SST problem. This problem was solved using all analog equipment 
rather than hybrid since the variables were within analog computer 
capability. The fundamental problem was to be able to get this entire 
problem on the six analog consoles shown. The complete analog program 
includes: the basic airframe dynamics, including six complete degrees 

of freedom and utilizing three 231-R consoles) the four independent 
engines requiring two consoles, and the subsystems including an autopilot 
using the sixth console. The aerodynamic forces and moments are simulated 
in the stability axis since the wind-tunnel data are with respect to this 
system. The forces are transformed to wind axis and the moments to body 
axis. The Euler angle equations are solved in wind axis because the 
conversion to earth coordinate is then simplified. As in all aerodynamic 
problems a large number of functions are required, the SST requires as 
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many as 75. These were generated by using servo set diode function 
generators which did “become a burden on the setup time. The programing 
of the four independent engines originally would have required 82 func- 
tions for the engine thrust and fuel flow which was beyond our function 
generation capacity. It was possible, however, to obtain two functions 
of one variable each, which when multiplied together would produce the 
family of curves required and reduce the number of function generations 
to 28. 


Operational Considerations 

Perhaps the most stringent requirement on this simulation is the 
operational restrictions. These operational restrictions are, namely, 
the difficulty of coordinating the efforts of approximately 150 personnel 
at four separate facilities and synchronizing and minimizing the equip- 
ment setup and checkout time at these facilities in order to meet a 
commitment to operate the simulator with NAFEC at 10:00 a.m. each morning. 
These operational problems are further complicated by the analog computing 
facility operation, which is on a two-shift basis,* The facility is used 
for other simulations on the second shift. This could, depending mainly 
on the number of DLFG (digital diode function generators) to be reset, 
require the entire SST computer program to be set up and checked out anew 
each morning. In order to overcome these difficulties, an organized 
sequence of events was used which allowed rapid setup and checkout of the 
computers and rapid location of errors when they occurred. Figure 4 shows 
this sequence of events used for the Langley end of the SST simulator. 

Each block or task will not be explained here, but all tasks are included 
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to show this sequence. On the left side of the figure the minimum time 
for completion of each task is shown. An attempt is made- to leave as 
many of the DDFG as possible set up from the day before without sacri- 
ficing any of the second shift problems. A special function check board 
is used to scan the functions quickly for accuracy and if any discrepancy 
occurs the DDFG reset tape is run for that particular DDIG. Time is saved 
during the static check by using a specially designed partial check, which 
examines only the main variables of an equation and then proceeds if no 
error occurs. If an error is present a detailed static check, which is 
available, is used to specifically locate it. The dynamic check is 
expedited by using transparent overlays for the time history recorders. 

All six ADIOS desks are working in parallel for the airframe as .well as 
for the engines and subsystems. The SST simulator setup and checkout are 

also progressing in parallel. The minimum time, which is based on every- 

* 

thing progressing without difficulty, is 1 hour and 35 minutes. The 
average time is about d hours and 35 minutes; therefore, most of tlie time 
the 10:00 a.m. commitment is met. These times also include a take-off 
check run with the pilot in the loop. With the amount of equipment involved 
these setup and checkout times are considered good. This SST simulator has 
been operating with NAFE3C since May 19&4. The schedule consists of approxi- 
mately three 5- to 8-week running periods per year and to date approximately 
700 runs have been made, roughly 450 of these have been run with NAFEC and 
have used experienced airline pilots. The SST cockpit has been used for 

( 

other problems when not used for air-traffic-control studies. 


LUNAR ORBIT AND LANDING APPROACH (LOW) STUDIES 
USING THE APOLLO LM TE?E VEHICLE 

General Considerations 

The LOLA project is currently the largest computer simulation at 
Langley. The main objective of this project is to help develop manual 
procedures that a pilot could use to control a space vehicle in the 
near vicinity of the moon by providing a complete simulation of the 
expected vehicle dynamics, control characteristics, and visual environ- 
ment to be encountered. 


Simulation Requirements 

Some of the more Important characteristics of the mission, the 
vehicles, and hardware which are of interest and which imposed difficult 
requirements on the computer programing and the mathematical model develop- 
ment are outlined below: 

Mission .- The following mission plans must be provided: 

(l) Multiorbit capability. 

12 ) Complete and continuous simulation from 200 nautical 
miles and terminating at approximately 150 feet, which includes the 
following phases: 

(a) Establishment of an 80-naut leal-mile orbit from 
an altitude of 200 miles. 

(b) Orbit transfer and coasting descent (Hohmann 
transfer) from the 80- nautical-mile orbit to perllune (50,000 feet) of 


the new orbit. 
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(c) Powered descent to approximately 10,000 feet. 

(d) Hover and landing approach to 150 feet. 

(3) Abort trajectories from either the powered descent 
or from the Hohmann transfer 

Vehicle . - The vehicle requirements consist of the following,* 

(1) Staging of the Apollo IM type vehicle (the IM type 
vehicle will be hereinafter referred to as the IM for simplicity) with 
the Apollo remaining in the 8o- nautical-mile orbit. 

(2) Staging of the IM descent vehicle to obtain the 
IM ascent vehicle. 

(3) Detailed simulation of the IM reaction control system 
(including four modes of control and 1 6 individual on-off reaction jets). 

(1+) Extensive moment description. 

Hardware . - In figure 5 is shown the main hardware of the LOLA 

simulator. The system consists of four progressively scaled models of 

the moon, two camera transport and track systems, and the pilot's cabin 

* 

and television display. Model 1 is a 20- foot- diameter sphere mounted on 
a rotating base and is scaled 1 in. = 9 mi. Models 2, and 4- are 
approximately' 15 X 4o feet scaled sections of m/Jdal X* Model 4 is a 
scaJed-iap section of the Crater Alphonsus and the scale is 1 in. = 200 ft. 
All models are in full relief except the sphere. The model system is 
designed so that a television camera is mounted on a camera boom on each 
transport cart and each cart system is shared by two models. The cart's 
travel along the tracks represents longitudinal motion along the plane 
of a nominal orbit, vertical travel of the camera boom represents latitude 
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on out-of-plane travel, and horizontal travel of the camera hoom 
represents altitude changes. A typical mission would start with the 
first cart positioned on. model 1 for the translunar approach and orbit 
establishment. After starting the descent, the second cart is readied 
on model 2 and, at the proper time, when superposition occurs, the 

i 

pilot’s scene is switched from model 1 to model 2. Then cart 1 is moved 

i 

! to and readied on model 3 • The procedure continues until an altitude of 

i 

l 

13 0 feet is obtained. The cabin of the LM vehicle has four windows which 
represent a k-3 0 field of view. The projection screens in front of each 
window represent 65 ° which allows limited head motion before the edges 

of the display can be seen. The lunar scene is presented to the pilot 

j 

! by rear projection on the screens with four Schmidt television projectors, 

i The attitude orientation of the vehicle la represented by changing the 

lunar scene through the portholes determined by the scan pattern of four 

| orthicons. The stars are front projected onto the upper three screens 

\ 

j with a four-axis starfield generation (starball) mounted over the cabin 

and there is a separate starball for the lower window. 

Mathematical Model and Computer Considerations 
It has become increasingly evident at the Langley installation, as 
the physical systems to be - studied on the computer become more complex, 

j-, 

that computer capabilities and the hardware must play a more direct role ! 

jf 

in the ultimate mathematical formulation of. the problem. This was a f 
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major consideration in the LOLA simulation. Figure 6 shows in block | 

I 

diagram form the equation distribution on vhe computer complex. For \ 
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simplicity, Interconnections between computer consoles are omitted. 

The total simulation utilizes six 221-R analog consoles, a TRICE (DDA) 
console, a PB 250 digital computer, a Mark III-S logic console, and 
three Euler angle computers, in addition to the hardware described 
previously. j,t 1 b not intended here to describe in any detail the 
equations involved; however, a few pertinent points should be mentioned. 

To obtain suitable resolution on the computer (because of the large ranges 
of variables) both the Apollo and LM trajectory equations were perturbated 
about a nominal circular orbit. The most suitable nominal orbit was one 
whose radius was equal to the actual elliptical orbit's semimajor axis 
distance, but programed from the center of the moon. This gave symmetry 
for the vehicle’s deviation from the nominal orbit, which allows optimum 
scaling. The perturbated trajectory equations for both Apollo and I M 
were programed on TRICE because of its excellent accuracy in calculation 
of orbital equations, and also because their configuration required a 
minimum of interface between the TRICE and the analog system. It would 
have been necessary to include TRICE anyway on a problem of this size, to 
be used as a seventh analog. With the serious limitation on equipment, 
it was necessary to keep duplication to an absolute minimum. Therefore, 
all vehicles were represented by the same equations of motion, with inputs 
from the same control system. This approach was possible, since no two 
vehicles were needed simultaneously, with the exception of the Apollo which 
remains in orbit, but needs no attitude description. For this reason two 
identical sets of equations of motion appear on the TRICE, and this exception 
requires the only significant duplication in the simulation effort. Notice 
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that the staging logic, ■which is used hoth in the separation of the 
Apollo and LM vehicle and the dropping of the landing stage from the 
IM descent vehicle to obtain the IM ascent vehicle, appears on four of 
the computer consoles. A significant amount of logic is involved at the 
time of staging for it requires switching from one set of characteristics 

t 

to another throughout the analog system. These characteristics include: 
mass, inertias, main thruster magnitude and direction, body rate magni- 
tudes, control system, and attitude. Euler parameters were used for the 
axis transformations, the advantages of which will be mentioned in the 
discussion of the next problem. The Packard-Bell 250 digital computer in 
addition to being used as a TRICE controller is used to make scale changes 
for the model drives. This function is accomplished by the PB 250 changing 
the scale of the variables in the TRICE registers when switching from one 
model to another occurs. This scale change is provided so that the cart 
assembly can always operate with full range on each model. If this change 
were made on the analog, the noise amplification would be intolerable 
since there is approximately a 250 to 1 ratio in the scaled lunar models. 
The Euler angle computers will be described in the discussion of the next 
problem. The logic console is used for the reaction jet logic in the 
vehicle control system and for the jet failure display drives for the 
cockpit display panels. All of the LOLA hardware is not yet complete, 
but should be in the next few months. The computer program is complete 
and the simulation has already been used for some interim studies on 
individual phases over the past 18 months. These include some preliminary 
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studies in orbit establishment and abort using model 1 and power descent v 
using model A. It is anticipated that this simulation will be useful 
for many lunar research studies over the next 2 to 3 years. 

GEMINI -AGENA STATION-KEEPING STUDIES 
General Description 

This is a real-time simulation of the Gemini (observer) vehicle 
station keeping with the Agena (target) vehicle in a slightly elliptical 
orbit. Some of the objectives and overall capabilities of this study 
were: 

(1) To investigate manual- control procedures (attitude and trans- 
lational) and fuel usage for station keeping with the Agena vehicle. 

(2) To evaluate pilot effectiveness for various control procedures. 

( 3 ) To evaluate ” onboard" equipment and flight data display require- 
ments. This evaluation was made with and without radar information. 

(^•) To study terminal rendezvous techniques and photographic study 
maneuvers . • 

Simulation Requirements 

Some pertinent characteristics of the mission, the vehicle, and the 
hardware which are of interest and which place difficulties on the mathe- 
matical model and computer program development are outlined below: 

Mission .- Mission requirements include: 

(l) Unlimited angular freedom of both target and obseryer 
vehicles, thus making it possible to approach the target from any spatial 
direction while the target vehicle is capable of completely independent 
angular motion. 
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(2) Generation of arbitrary target orbits. 

(5) Both the observer and target vehicles must have 
multiorbit capability in a real-time environment. 

(*}•) The model in conjunction with the visual docking 
simulator (VDS) provides a realistic ,f out -the -window" display. Proper 
target aspect is to be generated for arbitrary rotational and trans- 
lational motion of both the target and observer vehicles. 

(5) Has station-keeping and fly around capabilities. 

(6) Has complete eleven degrees of freedom, six for the 
observer vehicle and five for the target vehicle. 

Vehicle .- The vehicle requirements are: 

(1) Complete description of the Gemini vehicle with all 
jet controllers and cross couplings available. 

(2) Three different modes of attitude control: direct, 

rate command, and attitude hold. Translational controls are direct only. 

Hardware .- The hardware requirements may be best explained by 
referring to figure 7* This Visual Docking simulator is a Langley 
developed Virtual Image Display system which provides an "out-the-window” 
visual display of the target vehicle, a featureless horizon, and a 
starfield. The starfield and horizon projectors consist of point light 
sources projecting through and reflecting from a beam splitter to the 
upper screen. The girnbal angles involved, which are obtained from the 
computer, represent the attitude of the observer vehicle. The image 
of the Agena target vehicle is formed on the lower screen by a television 
projector. The input to the projector is the image of an Agena model 



■which is mounted in a two-axis ginibal and viewed by a vidicon camera. 

The two-axis girabal represents two of the three rotations of the target 

t 

vehicle relative to an axis system fixed to the line of sight from the 
observer to the target. The third (or rolling motion) is obtained by 
rotation of the vidicon about the line of sight. Line-of-sight range 
is obtained by moving the camera assembly longitudinally with respect 
to the model along a range bed. The mirror gimbals are driven in 
azimuth and elevation as a function of the target’s line-of-sight angles 
relative to the observer’s body axis, thus representing all eleven 
degrees of freedom of the two vehicles. The Images on the two projection 
screens are then mixed by the second beam splitter which is transparent 
to the target image but reflects the previously mixed horizon-starfield 
image. The composite image is then viewed by the pilot through a lens. 

A nominal instrument display, including a three- axis attitude Indicator 
for the observer, is provided. 

* 

Mathematical Model and Computer Considerations 
In addition to meeting mission requirements, perhaps the most 
stringent constraints imposed on the format of the trajectory mathematical 
model results from computer limitations and characteristics. An attempt 
was made to overcome some computing difficulties associated with the 
rendezvous class of piloted simulations by developing a trajectory model 
which is compatible with an Analog- TRICE (DDA) computing system. 

Figure 8, which is a general block diagram of the equation distribution 
on the computer complex, shows some of the computer assignments and 
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interconnections. Again, for simplification, interconnections between 
computer consoles are not shown. The total simulation utilizes five 
231-R analog consoles, a TRICE (DDA) console, four Euler angle computers, 
and the simulator complex that was described previously. Again, as in 
LOLA, it is not the intent here to describe in any detail the equations 
involved, but some pertinent points should be made. Since only the 
terminal phase of rendezvous is of interest in this simulation, relative 
equations of motion which greatly improve the scaling of the analog 
computer are used. Second-order correct gravity terms were used for the 
trajectory equations of the observer vehicle. Further scaling advantages 
are realized by perturbatlng the target equation of motion by using a 
similar approach as in LOLA. It is at this point that the hybrid concept 
is employed. The TRICE is capable of solving the perturbated target 
orbital equations very accurately for more than one orbit. In this case 
the TRICE is conceived as an open loop function generator for the target 
trajectory,, Throughout the other consoles there are seven sets of trans- 
formations from one axis system to another to satisfy the vehicle and 
hardwire requirements. Considering some of the mission requirements, such 
as unlimited motion of the vehicles and multiorbits, the quaterian approach 
(Euler parameters) was considered the best method of performing these 
transformations. The Euler angle approach is inadequate because of the 
singularities and the number of redundant integrators that would be 
required. The Euler rate equations are prohibitive mainly because of the 
complexity of the constraints required. Of course, the axis systems used 
cannot be chosen- independent of the type of transformations required. 


- 16 - 

They must be chosen to hold the number of transformations to a minimum. 
Three sets of Euler parameter equations are solved for the target, the 
observer, and the control platform for the observer. The control platform 
is provided to allow pilot selection of a new inertial system. The Euler 
angle computers (EAC) are special purpose devices consisting of a set of 
three resolvers which accept the direction cosines and produce the 
associated angles for the eight-ball, star ball, horizon generator, and 
the model. These angles would be obtained from the general-purpose 
computing equipment, such as a and (3 are on console No. 2, if the EAC’s 
were not available. Nearly all of console 1 is utilized by the control 
system. This complete system represents the mechanization of an eleven- 
degree- of- freedom, two-vehicle system, which provides the basis for a 
high-fidelity real-time simulation capable of performing all the mission 
requirements. This simulator has been used extensively over the past 
10 months in support of studies for GT-9, GT-10, and GT-11 missions. It 
did, however, require nominal modification for the Gemini-Agena tether 
simulation. 

BEAL- TIME DIGITAL SIMULATION OP THE 
GEMINI-AGENA STATION-KEEPING PROBLEM 

Introduction and Objectives 

The possibility of real-time digital simulation using general- 
purpose digital equipment in order to advance the state of the art of 
computer science has been under consideration, investigation, and 
various stages of application for some time. To investigate and gain 
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experience in this concept at LHC this project was undertaken. In order 
to make a direct comparison and prevent building another simulator, it 
was decided to duplicate the Gemlni-Agena station-keeping problem which 
had already been successfully simulated using the hybrid concept just 
discussed. Some of the specific objectives of this study were; 

(1) To demonstrate the feasibility of certain integration schemes. 

(2) To evaluate programing language suitability (FORTRAN). 

( 5 ) To determine the amount of Central Processing Unit (CPU) time 
required to complete an iteration to help determine multiprogram capa- 
bility in general. 

(4) To uncover possible trouble areas which may hinder program 
solving on Langley’s future real-time digital simulation facility. 

Complement of Equipment 

Figure 9 shows the equipment used in this simulation. The IBM 709^11 
digital computer solved the equations of motion. The 7090 buffer which 
is part of the TRICE equipment was used to transmit the word in parallel 
to and from the 709^ through the direct data channel. Extensive hardware 
modifications were performed on the buffer, the distributor, and the 
converters in order to handle the transmission of data reliably. The 
distributor is used to address the converters and to translate information 
from the 90 buffer into TRICE control functions. The sample and present 
timer is a real-time clock which allows transmission of data at the proper 
rate or time between the computer and the converters. The TRICE keyboard 
is used for mode control (the normal analog modes) of the computing system. 
Twenty- four digital-to-analog converters (DAC's) are used to send necessary 
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signals to the visual docking simulator, which was discussed before. 

These signals are used to drive the starball, horizon generator, the 
model, mirror, range, the range-rate meter, and three velocity meters. 

All the desired drive signals could not be sent because of the limited 
number of RAC's available. Only seven anaiog-to-dlgital converters (ADC's) 
were required to handle the attitude and translational controls and an 
attitude mode selection signal for the cockpit. 

Programing Considerations 

Program language .- The desired approach was to program the equations 
of motion by using FORTRAN TV for ease and simplicity of programing and 
not have to resort to the more complicated but more efficient machine 
language in order to hold down the CPU computation time. The first attempt 
was to avoid "do" loops and subroutines where possible, but it was later 
discovered that this was not necessary for this problem. The FORTRAN logic 
was very useful and was used extensively in the simulation of the pulse 
controllers. It was necessary, however, to use machine language (MAP) for 
the INPUT/OUTPUT program because the required statements did not exist in 
FORTRAN. 

Integration scheme and interval size .- It was considered desirable to 
use lower order multistep integration routines such as Adams Bashforth 
because of their speeds. The first attempt was to use Euler'.s routine. 

This routine proved adequate for the thrust and trajectory calculation 
because the rectangular scheme is best for the thrust's rectangular pulses 
and because the trajectory has an extremely low frequency. The Euler 
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routine, however, caused instability in the other equations which resulted 
in Intolerable errors in some of the variables. Second-order Adams Bashforth 
routine, however, did give adequate results. 

In choosing an interval size the attempt was to simplify the program 
by using only one Interval size if possible. Also, it was not an objec- 
tive to test the lower limits of updating the pilot display to avoid 
flicker or the lower limits of pilot control Inputs, which would only tend 
to confuse the investigation. Therefore, an arbitrary upper limit of 
50 milliseconds was chosen for the interval size, which was considered 
to be good enough to avoid noticeable display jumps, as long as truncation 
errors were tolerable. The interval-size lower limit is determined mainly 
by round-off errors. As a first attempt 15 milliseconds was tried, but 
generated too much round-off error. Finally, 31.25 milliseconds (which 
is a reciprocal power of two) was used successfully for the whole problem, 
which allowed 32 samples per second The solution was checked against a 
nonreal-tlme solution obtained by using, double precision fourth-order 
Runge-Kutta routine. The comparison was favorable and gave better agree- 
ment than the hybrid solution. The CPU time was estimated to be between 
3.75 and 4,0 milliseconds which leaves approximately 85 percent of the 
CPU time unused. Also, only 35 percent of the 32K core memory was used 
for this problem. 

General Comparison 

It was not necessarily an objective of this program to improve the 


accuracy over that of the hybrid system but to produce a man-in-the-loop 
digital simulation as acceptable as that of the hybrid. The overall 
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qualitative opinions of the research pilot who flew both simulations 
felt that the digital simulation performed as well as the hybrid. One 
task given the pilots for direct comparison was to determine a relative 
velocity component between the target and observer vehicle by visual 
techniques. The pilot would initiate a spacecraft maneuver as a result 
of visual sighting. The pilot would predict the unknown velocity after 
making another sighting 10 minutes later. This prediction waB then 

compared with the actual velocity. ' 

* 

Although this problem was not the utmost challenge to the digital 
computer, it was a typical problem and was chosen for that reason. The 
computer setup time was of course reduced considerably. The objectives 
of this simulation effort were for the most pan* satisfied and this 
approach was considered to be successful for this type of problem. More 
investigations in other areas are to continue. 

FUTURE DIGITAL COMPUTER COMFLEX AND CONCLUDING COMMENTS 

In the near future a large percentage of the real-time simulation 
problems at the Langley Research Center will be performed by using the 
digital computer complex for which a block diagram is shown in figure 10. 
A contract has already been awarded and delivery of the first system is 
scheduled for late in 19 66 . From a cursory look at this diagram, the 
main body of the system is noted to consist of three computers, Job Shop 
System-1 (JSS-l), Job Shop System-2 (JSS-2), and the Real-Time Simulation 
System (RTSS) . Computers JSS-l and JSS-2 will be used mainly for data 
processing and nonreal-time applications. All three computers will share 
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the extended core memory. The size of the core memories Is indicated 
in each block, ^12K, 65 K, 65 K, and 65 K. The approximate power of each 
computer based on the power of the 709^11 is shown. For example, the 
JSS-1 is 1.5 times (l.^X) more powerful than the 709^* Connected to 
the computer complex will be the auxiliary equipment shown in the six blocks 
in the lower part of the figure. Of major interest are the simulation 
application consoles (SAC^ and the conversion equipment. As many as 
six SAC's will be available for real-time simulation (RTS) studies and as 
many as six RTS problems, depending on the amount of CPU time and conversion 
equipment used by each, can be operating simultaneously in addition to jobs 
being processed in the nonresl-time categories. This will be possible due 
to the multiprogram capability of the computing system. Because of the 
extensive software which will be available (including an RTS monitor), 
it will not be necessary for the problem engineer to be concerned about 
the location of his program inside the computing system, but he needs only 
to communicate with the SAC. It will be possible, as on the analog, to do 
on-line checkout and program changes as well as actually to conduct the 
experiment. This will provide a realistic man- simulator interface relation- 
ship with nearly zero turn-around time. The conversion-equipment block 
will be connected to various simulators or to any piece of analog equip- 
ment. This discussion, of' course, has provided a brief look at the future i 

j* ; 

computer complex with the intent of indicating the direction that Langley jsj 

i 

H 

anticipates in simulation. ; 
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Again, the purpose of this presentation has been to acquaint other 
computer users with Langley’s approach to real-time simulation problems. 
Detailed aspects of the problems discussed will be contained in papers 
being prepared by various members of our staff for NASA publication. 
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Figure 2.- Langley SST simulator and control room 










AIRFRAME 


i 

START 

7:00 



PARTIAL 
SETUP AND 
CHECKOUT 

ENGINES AND 
SUBSYSTEMS 


SST 

SIMULATOR 


< ^ 'i 

r > 

7:20 ► 

FUNCTION 
CHECK BOARD 


FUNCTION 
CHECK BOARD 


PRELIMINARY 
PRE-OP CHECKS 


7:30. 


7.35 


7:55 


8 : 00 . 


8:10 


RESET 

TAPES 


BOARDS CHECKED 
AND 

ON MACHINE 



POT 

TAPES 


_3 



— 

STATIC 

CHECKS 



1 


DATA 

REDUCTION 
TRUNK CHECK 





— - 

DYNAMIC 

CHECK 


□ 



POT 

TAPES 



STATIC 

CHECK 


SETUP 

CHARTS 

ON X-Y PLOTTERS 


SETUP 
NAV AID 
STATIONS 


NAV AIDS 

dynamic 

CHECKS 


STATIC 

CHECK 


CONTROL 

CALIBRATION 

AND 

CLOSURE 

CHECKS 



MAPS 


lirA no 

fl*1R 

i 


— 

MAirb 




TAKE OFF 


— 1 — 

8:35 


► 

CHECK RUN 



PARTIAL - MINIMUM 1:35 AVERAGE 2:35 

t 

RUN 


Figure 4.- Set-up and check-out sequence. 
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Figure 5.- Lunar orbit landing approach simulator. 
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Figure 7* - Visual docking simulator. 
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Figure 9.- Equipment utilized for digital simulation of Gemini -Agena 

station-keeping studies. 



EXTENDED CORE MEMORY 512K 


i 

... r~ 


JSS-l 


JSS-2 


RTSS 

65K 


65K 


65K 

L5X 


sx 


25X 



I 


SIMULATION — 

CONVERSION 

AND 

HARDWARE 

DISCRETE 


EQUIPMENT 


r~ 

* 

PERIPHERAL 

EQUIPMENT 


1 


REMOTE 

CONSOLES 



Figure 10.- Block diagram of Langley Research Center’s future computing 

complex. 
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